Method and device for the transmission of data in a television system

ABSTRACT

The invention concerns a method for transmitting binary data in a video transmission system. The method comprises the steps of providing ATVEF announcements on a first predefined IP multicast address; providing ATVEF trigger and/or content transmission on a first range of IP multicast addresses; providing non-ATVEF announcements on a second predefined multicast address different from said first address; and providing non-ATVEF data transmission on a second range of IP multicast addresses, exclusive of the first range. The invention also concerns an emitter and a receiver for implementing the method.

This application claims the benefit under 35 U.S.C. §365 ofInternational Application PCT/EP01/12333 filed Oct. 18, 2001, whichclaims the benefit of European patent application No. 00402921.1 filedOct. 23, 2000.

FIELD OF THE INVENTION

The invention concerns a method for transmitting data in a televisionsystem, as well as an emitter and a receiver in such a system. Theinvention applies in particular, but is not limited to, systemsimplementing the ATVEF specification.

BACKGROUND INFORMATION

Television receivers are being developed to host resident interactiveservices, transmitted for example through a bi-directional returnchannel or simply broadcast over the same channel as the video signal.In this context, ATVEF (Advanced TeleVision Enhancement Forum) specifiesthe use of a number of protocols such as IP multicast (Internet Protocolmulticast) for transporting data for interactive television programenhancement services over a number of transmission media.

According to the ATVEF specification, when a service provider wishes totransmit an interactive service, he first has to transmit a messagecalled an announcement, containing information describing theinteractive service. This announcement is transmitted to a specific IPmulticast address and to a specific port, known to all receivers (IPaddress 224.0.1.113 and UDP Port 2670).

Receivers compatible with the ATVEF specification continuously monitorthis address/port couple. Their resident software modules retrieve theannouncement, which contains a pair of IP addresses, one for thetransmission of the interactive service (called the ‘content’), anotherone of the transmission of triggers. Triggers are messages fortriggering a certain behavior of interactive services at predeterminedmoments.

Software modules resident in the receivers may require updates. Forflexibility reasons, it should be possible to make such an update inremote fashion, i.e. to transmit the updated software modules to thereceivers in situ. Such a transmission should obviously use some of thealready available transmission media, such as the return channel (be itthrough the PSTN or the cable network, or another type of bi-directionalcommunication means) or the television broadcast medium.

The ATVEF protocol stack (see FIG. 1 a) cannot be used directly totransmit the update—or other types of binary data—, because the softwarein charge of retrieving the interactive service (e.g. a browser) is notable to interpret the content data which represents the residentsoftware module update. This update is typically binary data, instead ofthe UHTTP data expected by the browser. This could result inunpredictable behavior at the receiver level. Modifying the browser todetect and process binary data would be impractical. In addition,transporting binary data using UHTTP is cumbersome, since this protocolhas not been developed for such a purpose.

Nevertheless, it is desired to respect as much a possible the ATVEFprotocol, to remain within the constraints defined by the broadcasttools.

SUMMARY OF THE INVENTION

The object of the invention is a method for transmitting binary data ina video transmission system comprising the steps of:

-   -   providing ATVEF announcements on a first predefined IP multicast        address;    -   providing ATVEF trigger and/or content transmission on a first        range of IP multicast addresses;    -   providing non-ATVEF announcements on a second predefined        multicast address different from said first address;    -   providing non-ATVEF data transmission on a second range of IP        multicast addresses, exclusive of the first range.

According to an embodiment of the invention, said system comprises anemitter comprising a data inserter for inserting ATVEF and non-ATVEFinformation into a transmission signal, said method further comprisingthe steps of:

-   -   providing ATVEF announcements and non-ATVEF announcements to the        data inserter,    -   dynamic insertion of IP multicast addresses by the data inserter        into the announcements, in accordance with the first and second        ranges.

According to an embodiment of the invention, the method furthercomprises the step of splitting each of the first and/or the secondrange of IP multicast addresses into a third and a fourth range, wherethe third range is reserved for automatic address determination by thedata inserter, and the fourth range is reserved for addresses which arepredefined in the announcements provided to the data inserter.

According to an embodiment of the invention, ranges are distinguished bydifferent IP address ranges, different port ranges or both.

According to an embodiment of the invention, at the level of a receiver,the method further comprises the steps of:

-   -   receiving a non-ATVEF announcement announcing transmission of        receiver software update data, said announcement containing an        IP multicast address on which signaling data describing the        update data transmission is to be sent;    -   listening to the address specified in the announcement;    -   retrieving the signaling data and storing it in a memory which        is not erased during download of the update data;    -   launching of a loader program;    -   having the loader program retrieve the stored signaling data;        and    -   proceeding with the download of the update data based on the        stored signaling data.

Another object of the invention is an emitter device for broadcastingannouncements in a transmission system compatible with ATVEFtransmissions, characterized in that it comprises means for transmittingATVEF announcements on a first predefined IP multicast address, ATVEFtrigger and/or content data on a first range of IP multicast addresses,binary data announcements on a second predefined IP multicast addressdifferent from the first predefined address and binary data on a secondrange of IP multicast addresses, wherein the first and second addressranges are exclusive of each other.

According to an embodiment of the invention, the emitter comprises meansfor receiving an announcement, for determining whether the announcementcomprises a predetermined IP multicast address in a first range, and inthe negative, for selecting an IP multicast address in a second range,distinct from the first range, and for inserting the selected IPmulticast address into the announcement.

Another object of the invention is a receiver in an ATVEF compatibletransmission system, characterized in that it comprises a memory forstoring a first predefined IP multicast address for receiving ATVEFannouncements, and a second predefined IP multicast address forreceiving announcements relating to the transmission of binary data,where the first and second addresses are distinct.

According to a variant embodiment, the receiver further comprises amemory for receiving a third multicast address on which binary datatransmission is announced, said memory being such as to maintain themulticast address during a receiver reboot process, said receiverfurther comprising means for listening to the third multicast address inthe memory after reboot for downloading the binary data from said thirdmulticast address.

According to an embodiment, the third multicast address on which binarydata transmission is announced is provided in signaling data announcedon said second multicast address.

According to an embodiment, the downloaded binary file is a completesystem update.

Other characteristics and advantages of the invention will appearthrough the description of a detailed, non-limiting embodiment,explained with the help of the attached drawings, among which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a (prior art) represents an ATVEF protocol stack;

FIG. 1 b represents a protocol stack of a device according to theembodiment;

FIG. 2 represents the software structure of a receiver, as well asdifferent applications and tasks and their evolution upon reception ofan announcement;

FIG. 3 is a flowchart of the processing of announcements and data by areceiver according to the invention;

FIG. 4 is a flowchart of the processing of announcements in a broadcastserver;

FIG. 5 is a schematic diagram illustrating the principle of acquiring anIP multicast address in a first step when the receiver is in nominalmode and using the stored IP multicast address in a second step duringwhich the receiver is in a loader mode;

FIG. 6 is a schematic diagram of a network comprising an emitter andreceivers according to the present embodiment.

DETAILED DESCRIPTION OF THE INVENTION

In the figures, the symbol ‘@’ is used to designate an address.

More information concerning the ATVEF specification can be found in thedocument “Enhanced Content Specification” ATVEF (Advanced TeleVisionEnhancement Forum) Specification v 1.1 r26. This document is availablefor example on the ATVEF website.

Reference is also made to the document ‘SDP: Session DescriptionProtocol’, Internet Society, Network Working Group, RFC 2327 of Apr.1998.

Announcements according to the ATVEF specification follow the formatdescribed in the SDP document mentioned in the previous paragraph,though ATVEF imposes some restrictions for some parameters. Parametersused in an SDP announcement according to the ATVEF specification are asfollows:

-   -   Session Description    -   v=protocol version, equal to 0    -   o=username, session identifier, version, network type (equal to        IN in the present case), address type (equal to IP4 in the        present case), ipaddress    -   s=session name    -   i=session information (optional)    -   u=Universal Resource Identifier (URI) of a description of the        enhancement (optional)    -   e=email address    -   p=phone number (at least one of the e and p parameters is        required)    -   b=CT:number (bandwidth information)    -   c=connection information

The following session attributes can or must be used:

-   -   a=UUID:UUID (Universally Unique Identifier: unique enhancement        identifier-optional)    -   a=type:tve    -   a=lang, a=sdplang (optional language attributes)    -   a=tve-type:<types> (optional)    -   a=tve-size: Kbytes    -   a=tve-level:x (optional)    -   a=tve-ends:seconds (optional)

Media Description

-   -   m=(media name and transport address)

Time Description

-   -   t=(time during which the session is active)

As has already been mentioned in the introduction, ATVEF announcementsare sent to a predefined IP address (224.0.1.113) and a predefined UDPport number (2670).

The parameter ‘c’ of an announcement indicates to which address contentand triggers will be sent, while the parameter ‘m’ indicates on whichport they will be sent. Triggers and content may be sent on differentports at the same address, as well as on different addresses.

The present embodiment concerns an analog television system in which thevertical blanking interval lines of the analog video signal are used totransmit digital data. Modulation of this kind of data on an analogtelevision signal is well known per se.

FIG. 1 b is a diagram of the protocol stack used by a receiver inconformance with the present embodiment. Compared to the ATVEF stack ofFIG. 1 a, the UHTTP layer has been replaced by a proprietary layer. Thestack includes UDP (User Datagram Protocol) over IP (Internet Protocol),SLIP (Serial Line Internet Protocol) and IDL-B, as defined in ETS 300708.

The role of the proprietary layer is to manage binary data downloading.The binary data to be downloaded is split into sections having the sizeof IP packet payloads, i.e. 1472 octets. The layer assembles thedifferent sections it receives in the right order. If a section containsuncorrectable errors, then the proprietary layer waits for a nexttransmission (see below) and inserts it at its proper place.

The proprietary layer also retrieves date/time information andannouncements relating to binary data downloads and date/timeinformation.

Enhancements and binary data are usually sent repeatedly, in order toenable receivers to access the corresponding data even when they do notlisten from the beginning of the transmission, and in order to retrievepackets which were previously received with uncorrectable errors.

According to the present embodiment, in order to announce thetransmission of binary data, an announcement of the SDP format is madeat another address and port than the address and port used by the ATVEFannouncements. Accordingly, as an example, the receiver listens to theaddress 235.0.1.113, port number 2670, to detect these novel types ofannouncements. In parallel, the receiver continues to listen to thestandard ATVEF announcement address and port.

FIG. 2 is a diagram of an example of the applications and tasks that areceiver according to the present embodiment runs in parallel accordingto the present embodiment. Of course, other applications and tasks mayalso run, but are not directly relevant to the present embodiment. Thereceiver listens to six different IP multicast addresses, numbered A1 toA6. An IP multicast address comprises an IP address and a port number.An ATVEF announcement is sent to the well-known ATVEF address/portcouple A1 as already described above. ATVEF content and triggers (‘ATVEFdata’) is sent to two different address/port couples, A3 and A4, whichare specified by the ATVEF announcement. Two different non-ATVEFannouncements are sent to predefined, fixed address/port A2. The firstone indicates an address/port A5 for retrieving date and timeinformation, while the second one indicates an address/port A6 forretrieving the binary data.

Applications of FIG. 2 act upon a socket layer 4 to listen to therequired IP multicast addresses. The socket layer 4 operates over anoperating system 5 including a VBI Driver (which is not illustrated).The Vertical Blanking Interval (VBI) driver retrieves data from the VBIof the incoming analog video signal. Of course, in case anothertransmission path were used (e.g. all digital television signal such asan MPEG II Transport Stream), another driver than the VBI Driver wouldbe used. The retrieved data is under a packet format called IDLB. Thedriver extracts the payload from these packets and applies an errorcorrection process. The payload is a SLIP-format stream which enablesthe driver to identify and separate IP packets. Once the SLIP layer hasbeen removed and the IP packets have been reconstructed, the driverhands these packets over to the upper layers in charge ofde-encapsulating the IP and UDP layers. The browser 1 and the otherapplications are clients of the socket layer 4 which enables them tolisten to an IP address and a UDP port in order to retrieve thetransmitted content.

The upper part of FIG. 2 will be described first. The upper and lowerparts show the receiver's state at different moments in time.

The receiver runs a browser 1 in charge of retrieving respectively theATVEF announcements, content and triggers and listens respectively toaddresses A1, A3, A4, which the browser 1 has programmed at the socketlevel). In FIG. 2, it is supposed that at least one announcement hasalready been received. The browser may also listen to other addresses,which are not shown on FIG. 2. A first task 2 (‘Binary data fetchingmanager’) is in charge of retrieving the non-ATVEF announcements sent onaddress A2. A second task 3 (‘Code download signaling data retriever’)is used to retrieve the binary file itself on an address A6. The addressA6 has previously been specified in a binary announcement on address A2.Two different tasks are used to retrieve the update announcement and theupdate file itself: this avoids having to sort the incoming datarelating to these addresses.

The second task 3 need not be active all the time. It can be triggeredby the first task 2, upon reception of an announcement relating to thekind of data retrieved by the second task 3.

According to the present embodiment, the ‘i’ field of an announcement isused to inform the task 2 of the nature of the data to be transmitted.For example, ‘i’ is equal to ‘code download’ for the transmission ofbinary data, and equal to ‘date&time’ for the transmission of the dateand time information.

Contrary to ATVEF announcements, the announcement according to thepresent embodiment contains only one address and associated port value,to indicate to the receiver where to listen for the transmission of thebinary data (code update, time, or other).

According to the present embodiment, such an announcement contains thefollowing parameters relating to the address and port of the updatefile:

m=data 22814 tvpe-file c=IN IP4 235.37.32.27.

Other parameters are similar to those used in ATVEF announcements. Thisis given as an example: other values may be used as well.

As an example, a non-ATVEF announcement contains the following fields:

“v=0” see ATVEF

“i=XXX” see below

“a=UUID:XXX” see ATVEF

“a=tve-ends:XXX” or “t-start stop” see ATVEF

“m=data XXX tve-file” see above and ATVEF

“c=IN IP4 XXX” see above and ATVEF

FIG. 2 also illustrates the dynamics of announcement handling in thereceiver. The upper part of FIG. 2 shows the receiver's task at a timet. At this time, the browser 1 listens to its predetermined ATVEFannouncement address A1, and to two further addresses for content (A3)and triggers (A4). The binary data fetching module 2 listens to theaddress corresponding to binary data announcements.

At a given time, a binary announcement concerning the transmission ofdate and time is received by the binary data fetching module 2. Thisannouncement contains an IP multicast address A5 on which data and timeinformation is due to be transmitted. As illustrated by the lower partof FIG. 2, a third task 6, named ‘Date and time data retriever’ islaunched, in order to listen to the address A5 specified in theannouncement.

FIG. 3 is a flowchart which further illustrates the processing of ATVEFand non-ATVEF announcements and data in the receiver.

It must be noted that from the point of view of the implementation, thetest of whether an announcement is an ATVEF announcement or notcorresponds in fact to the filtering carried out using the different IPmulticast addresses.

The field “a=UUID” serves to identify the announcement. If theproprietary layer, in its role of binary data fetching module, alreadyreceived an announcement with the same UUID value although theexpiration date of this announcement has not yet been reached, the newannouncement is ignored. It is up to the operator to modify the UUIDvalue in order to inform receivers of an announcement content change.This mechanism avoids having to further process announcements if theirUUIDs correspond to those of already existing announcements.

When preparing an announcement, the service provider or thebroadcaster's emitter selects the address values for data transmissionin a certain range. According to the present embodiment, one such rangeis reserved for ATVEF transmissions, while another such range isreserved for non-ATVEF transmissions (e.g. software module updatesaccording to the present example). This avoids having ATVEF data sent tonon-ATVEF addresses and vice-versa.

Through this mechanism, different kinds of services may easily bemultiplexed.

FIG. 4 is a flowchart of the announcement creation process in a server,showing how IP multicast addresses are automatically selected andinserted into announcements by the emitter in the absence of presetaddresses.

In a preferred embodiment, the broadcaster receives the ATVEF ornon-ATVEF announcements and dynamically adds through its emitter thecontent, trigger or binary data transmission addresses according to thepredefined ranges.

As an example, the following address range is used for sending ATVEFenhancements on manually attributed addresses:

224.0.0.0 to 224.0.1.112 port numbers 0 to 2669.

The following address range is used for sending ATVEF enhancements onautomatically attributed addresses:

224.0.1.114 to 234.255.255.255, port numbers 2671 to 65535.

The following address range is used for sending binary files on manuallyattributed addresses:

235.0.0.0 to 235.0.1.112, port numbers 0 to 2669.

The following address range is used for sending binary files onautomatically attributed addresses:

235.0.1.114 to 239.255.255.255, port numbers 2671 to 65535.

Manually attributed addresses are addresses which are predetermined inannouncements received by the emitter from e.g. the service provider,i.e. the emitter does not itself select such addresses, as opposed toannouncements were such a choice is made automatically by the emitter,when at least one address is missing in an announcement. Differentaddress ranges are used to avoid having the emitter pick an addresswhich has already been defined manually in another announcement.

According to a variant embodiment, the address ranges used for ATVEF andnon-ATVEF data transmissions are the same or at least overlap to acertain extent, but the port number ranges attributed to each kind ofdata transmission do not overlap. In other words, there will still bedifferent IP multicast address ranges.

The two address ranges may be modified. In this case, an updatemechanism is put in place at the receiver.

A variant embodiment, illustrated by FIG. 5, will now be described. Thisembodiment concerns the case in which the binary data to be downloadedmay influence—and in particular interrupt—certain processes of thereceiver.

One can consider a receiver in which downloading of executable code, forexample all updatable code stored in a flash memory of the receiver, isto be performed. The receiver comprises a loader program 7 in order toperform the download. This program is stored in ROM, since all codestored in the flash memory is to be replaced.

The process in such a case is the following:

When the binary data fetching module receives a non-ATVEF announcementfor an update, it starts a specific task (the code download signalingretriever of FIG. 2), which listens to an address specified in theupdate announcement. The code to be downloaded is not sent to thisaddress, eventually with other signaling information describing thedownload to be carried out. Instead, this address receives a streamwhich describes the upcoming download, and in particular a downloadaddress. The code download signaling data retriever task stores thisaddress in a predefined location in the flash memory 8 of the receiver,this location being protected from being erased during the subsequentdownload. When the download is to begin, the task reboots the decoder.The loader 7 is then launched. This program fetches the download addressfrom the flash memory and downloads the code from this address. Thisupdate process may also be used in other environments than that of thepresent embodiment (i.e. environments not related to ATVEF).

FIG. 6 is a schematic diagram of a network comprising an emitter 51, anda plurality of receivers 52 i. The emitter comprises a video signalsource 53, a data inserter 54 controlled by a broadcast server 61. Thebroadcast server 61 is connected to a database 55, containing ATVEF andnon-ATVEF data and announcements. The data inserter inserts data intothe VBI lines of the video signal in an appropriate format, undercontrol of the broadcast server, which defines timing and allocatessignal resources. Data in database 55 may be provided by differentsources, in particular a service provider 56. The broadcast server 61automatically selects addresses as explained above, in case such anautomatic selection is required. Receivers also comprise amicroprocessor 57, a ROM 58 with a loader program 59 mentioned above, aswell as a register or memory 60 adapted to hold a multicast addressduring receiver reset and/or reboot and/or power loss.

Although the present embodiment mainly concerns ATVEF-type protocols,the invention is not limited to that environment. In particular, otherannouncement formats than those of the ATVEF or SDP announcements may beused. The split multicast address ranges according to data type inparticular constitutes an invention which may be employed in an otherenvironment.

Lastly, although the embodiment above concerns an implementation usingthe vertical blanking interval of an analog video signal to transmit theenhancement and update data, the invention can easily be applied withinother system, in particular all-digital transmission systems.

The emitter and receiver in the described system both comprisesprocessing means such as a microprocessor (reference 57 in receivers ofFIG. 5) and memory, for processing and respectively sending or receivingannouncements, triggers, enhancement content and binary data.

1. Method for transmitting receiver resident software module updates ina video transmission system comprising the steps of: providing anannouncement of an interactive television service on a first predefinedIP multicast address; providing a trigger for at least one of saidinteractive television service and a content transmission on a firstrange of IP multicast addresses; providing an announcement of a receiverresident software module update on a second predefined IP multicastaddress different from said first predefined IP multicast address, saidannouncement describing a download address of an upcoming download ofsaid receiver resident software module update, said download addressbeing chosen from among a second range of IP multicast addresses,exclusive of the first range; providing said download of said receiverresident software module update on said download address, said first andsaid second ranges of IP multicast addresses are split according to datatype, said data type being one of said at least one of said interactivetelevision service and a content transmission or said receiver residentsoftware module update.
 2. Method according to claim 1, wherein saidvideo transmission system comprises an emitter comprising a datainserter for inserting said at least one of said interactive televisionservice and content and receiver resident software module updateinformation into a transmission signal, said method further comprisingthe steps of: providing announcements said at least one of saidinteractive television service and content and said receiver residentsoftware module update announcements to the data inserter, and dynamicinsertion of IP multicast addresses by the data inserter into theannouncements, in accordance with the first and second ranges.
 3. Methodaccording to claim 2, further comprising the step of splitting the firstand the second range of IP multicast addresses into a third and a fourthrange, where the third range is reserved for automatic addressdetermination by the data inserter, and the fourth range is reserved foraddresses which are predefined in the announcements provided to the datainserter.
 4. Method according to claim 1, wherein ranges aredistinguished by different at least one of: different IP address ranges,and different port ranges.
 5. The method of claim 1 where the firstrange of IP multicast addresses is allocated for said at least oneinteractive television service and a content transmission and saidsecond set of IP multicast addresses are for said receiver residentsoftware module update.
 6. Emitter device for broadcasting announcementsin a transmission system compatible with a transmission of aninteractive television service, comprising: a means for transmittingannouncements of interactive television service on a first predefined IPmulticast address, trigger of at least one of said interactive serviceand content data on a first range of IP multicast addresses,announcements of a receiver resident software module update on a secondpredefined IP multicast address different from the first predefinedaddress, said announcements of a receiver resident software moduleupdate describing a download address of an upcoming download of saidreceiver resident software module update, said download address beingchosen from among a second range of IP multicast addresses, exclusive ofthe first range and said receiver resident software module update on asecond range of IP multicast addresses where said first and said secondranges of IP multicast addresses are split according to data type, saiddata type being one of said at least one of said interactive televisionservice and a content transmission or said receiver resident softwaremodule update.
 7. Device according to claim 6, further comprising areceiver for receiving an announcement, for determining whether theannouncement comprises a predetermined IP multicast address in a firstrange, and in the negative, for selecting an IP multicast address in asecond range, distinct from the first range, and for inserting theselected IP multicast address into the announcement.
 8. The emitterdevice of claim 6 where the first range of IP multicast addresses isallocated for said at least one interactive television service and acontent transmission and said second set of IP multicast addresses arefor said receiver resident software module update.
 9. Receiver in aninteractive television service compatible transmission system,comprising: a memory for storing a first predefined IP multicast addressfor receiving an announcement of an interactive television service,receiving a trigger for said interactive television service on a firstrange of IP multicast addresses, and for storing a second predefined IPmulticast address for receiving receiver resident software module updateannouncements, said receiver resident software module updateannouncements describing a download address of an upcoming download of areceiver resident software module update, said download address beingchosen from among a second range of IP multicast addresses, exclusive ofthe first range, where the first and second predefined IP multicastaddress are distinct, said first and said second ranges of IP multicastaddresses are split according to data type, said data type being one ofsaid interactive television service or said receiver resident softwaremodule update, the receiver further comprising a memory for storing saiddownload address, said memory for storing said download address beingsuch as to maintain said download address during a receiver rebootprocess; means for listening to the said download address in the memoryfor storing said download address after said receiver reboot process fordownloading the receiver resident software module update from saiddownload address, and wherein the download address is comprised insignaling data announced on said second predefined IP multicast address.10. Method for receiving data in a video transmission system comprisingthe steps of: receiving announcements of interactive television serviceson a first predefined IP multicast address; receiving trigger ofinteractive television services and/or content transmission on a firstrange of IP multicast addresses; receiving announcements of a receiverresident software module update on a second predefined IP multicastaddress different from said first predefined IP multicast address, saidannouncement describing a download address of an upcoming download ofsaid receiver resident software module update, said download addressbeing chosen from among a second range of IP multicast addresses,exclusive of the first range; receiving receiver resident softwaremodule update data transmission on said download address, where saidfirst and said second ranges of IP multicast addresses are splitaccording to data type, said data type being one of said at least one ofsaid interactive television service and a content transmission or saidreceiver resident software module update.
 11. Method according to claim10, comprising, at the level of a receiver, the steps of: receiving saidannouncement of receiver resident software module update announcingtransmission of receiver resident software module update data, saidannouncement containing an IP multicast address on which signaling datadescribing the receiver resident software module update datatransmission is to be sent; listening to the address specified in theannouncement; retrieving the signaling data and storing it in a memorywhich is not erased during download of the receiver resident softwaremodule update data; launching of a loader program; having the loaderprogram retrieve the stored signaling data; and proceeding with thedownload of the receiver resident software module update data based onthe stored signaling data.
 12. The method of claim 10 where the firstrange of IP multicast addresses is allocated for said at least oneinteractive television service and a content transmission and saidsecond set of IP multicast addresses are for said receiver residentsoftware module update.